kernel: Add Kconfig option to disable LTO for kernel sources #99124

GTLin08 · 2025-11-08T12:56:31Z

Some SoCs require kernel code to be placed in RAM, which makes link-time optimization (LTO) unsuitable for these files.
Disabling LTO allows the affected code to be linked as separate objects and placed in specific memory regions.
Running kernel code from RAM can improve execution performance, especially for timing-critical routines or context switch paths.

Another commit is to enable KERNEL_NO_LTO when SOC_IT8XXX2_KERNEL_IN_RAM and LTO are enabled on the IT8XXX2 chip.

fabiobaltieri · 2025-11-10T07:28:55Z

soc/ite/ec/it8xxx2/kernel_no_lto.cmake

+# Append the injected code to the end of the file
+file(APPEND ${KERNEL_CMAKE} "${INJECT_CODE}")


uh, why is this needed? The whole append/remove thing feels a bit hacky to be honest, hope we can find a different solution, you just need the -fno-lto -g in the build command line for the files above right?

The reason is that setting -fno-lto elsewhere (e.g. board-level CMake) didn’t work likely because of build order issues. Kernel sources were still built with LTO, so I had to apply it directly here to make sure those files compile without LTO and can reside in RAM.

ok so this is basically touching the source file to somehow convince cmake to build it again with the new flag?

Yes, that's correct, it temporarily modifies the kernel CMake file to ensure those specific sources are rebuilt with -fno-lto. After the build configuration is complete, the injected changes are automatically cleaned up to restore the original file state.

Got it. I don't really think it's a good idea to try and modify non generated files from the build script, @tejlmand do you have a better approach to suggest?

Would we not be able to get away with adding a Kconfig flag and the options in the kernel CMakeLists.txt file directly? If this SoC has a scenario where having a kernel specific option to selectively not do LTO it may be handy for other devices too.

Instead of modifying the kernel's CMake file, what about creating a separate CMake file that defines the no-LTO and other desired properties?

You could have the kernel CMake file do a conditional include based on a CONFIG option being set.

Thanks @fabiobaltieri and @keith-zephyr for the helpful suggestions.
I’ve updated the implementation accordingly. It now adds a Kconfig option to control the behavior, and the logic is handled inside kernel/CMakeLists.txt without modifying it from external scripts. Additionally, I’ve added a separate kernel_no_lto.cmake file to define the no-LTO settings.

kernel/Kconfig

keith-zephyr · 2025-11-12T16:20:13Z

kernel/kernel_no_lto.cmake

+     NOT src MATCHES "errno\\.c$" AND
+     NOT src MATCHES "fatal\\.c$" AND
+     NOT src MATCHES "init\\.c$")


Should these files be added to the LTO_ALLOWLIST as the default settings?

Agreed, I’ve added them to the default LTO_ALLOWLIST. Thanks!

GTLin08 · 2025-11-13T06:00:27Z

@fabiobaltieri Please revisit, thanks!

fabiobaltieri

@tejlmand does this look like an acceptable approach?

npitre · 2025-11-13T16:09:09Z

Just wondering... Can't you do a partial linking with LTO of the kernel and the application separately, then join them with a final link?

keith-zephyr · 2025-11-13T18:37:00Z

kernel/Kconfig

+	help
+	  List of kernel source filenames that should retain LTO even when
+	  CONFIG_KERNEL_NO_LTO is enabled.
+	  Example: CONFIG_KERNEL_LTO_ALLOWLIST="init.c errno.c fatal.c"


Did you want to make these files the default setting? Otherwise you could expand the help text to suggest this list as a good default as these features don't benefit from the performance gain of running in RAM.

If we set default "init.c errno.c fatal.c" for CONFIG_KERNEL_LTO_ALLOWLIST, users would still need to override the entire string when adding more files. Kconfig does not support appending to the default value, so it cannot be extended incrementally.

Acknowledged. As a follow up PR, you could enable CONFIG_KERNEL_NO_LTO on the ITE eval board so that there is a reference implementation for users to copy.

Sure, once this PR is merged, I’ll create a follow-up PR to enable.

GTLin08 · 2025-11-14T05:32:46Z

Just wondering... Can't you do a partial linking with LTO of the kernel and the application separately, then join them with a final link?

@npitre , Thanks for the suggestion. My concern is that even with partial linking, once LTO is applied, the compiler may still inline or merge functions across the participating kernel files. This means I can no longer obtain the original libkernel object files or their sections that must be placed in RAM.

My current approach explicitly applies -fno-lto to the RAM-critical kernel sources, which guarantees their object layout remains intact. This is required so we can reliably place those routines into RAM for performance.

kernel/Kconfig

kernel/kernel_no_lto.cmake

GTLin08 · 2025-11-18T10:16:22Z

@tejlmand, Any feedback would be greatly appreciated.

nordicjm · 2025-11-19T10:22:01Z

kernel/Kconfig

+	  for timing-critical routines or context switch paths.
+
+if KERNEL_NO_LTO
+config KERNEL_LTO_ALLOWLIST


this should be done in CMake using functions not Kconfig

Thanks for the suggestion. I’ve removed the KERNEL_LTO_ALLOWLIST Kconfig option and switched to using a CMake function as recommended.

Some SoCs require kernel code to be placed in RAM, which makes link-time optimization (LTO) unsuitable for these files. Disabling LTO allows the affected code to be linked as separate objects and placed in specific memory regions. Running kernel code from RAM can improve execution performance, especially for timing-critical routines or context switch paths. Signed-off-by: Tim Lin <tim2.lin@ite.corp-partner.google.com>

Select KERNEL_NO_LTO only when LTO is enabled. This ensures proper handling when kernel code is placed in RAM. Signed-off-by: Tim Lin <tim2.lin@ite.corp-partner.google.com>

sonarqubecloud · 2025-11-21T11:28:33Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

zephyrbot added platform: ITE ITE area: Boards/SoCs labels Nov 8, 2025

zephyrbot requested review from Chenhongren, Dino-Li, RuibinChang, fabiobaltieri and keith-zephyr November 8, 2025 12:58

zephyrbot assigned Dino-Li, GTLin08, RuibinChang and Chenhongren Nov 8, 2025

fabiobaltieri reviewed Nov 10, 2025

View reviewed changes

fabiobaltieri requested a review from tejlmand November 10, 2025 07:29

GTLin08 force-pushed the it8xxx2_kernel_in_ram_lto branch from d69e872 to e660d0d Compare November 11, 2025 06:46

zephyrbot added the area: Kernel label Nov 11, 2025

zephyrbot requested review from TaiJuWu, andyross, ceolin, cfriedt, dcpleung, nashif, npitre and peter-mitsis November 11, 2025 06:48

GTLin08 changed the title ~~it8xxx2: ensure kernel in ram code section~~ kernel: Add Kconfig option to disable LTO for kernel sources Nov 11, 2025

fabiobaltieri reviewed Nov 11, 2025

View reviewed changes

kernel/Kconfig Show resolved Hide resolved

GTLin08 force-pushed the it8xxx2_kernel_in_ram_lto branch from e660d0d to 123ab0b Compare November 11, 2025 10:08

fabiobaltieri assigned tejlmand and unassigned Chenhongren, Dino-Li and RuibinChang Nov 11, 2025

fabiobaltieri unassigned GTLin08 Nov 11, 2025

fabiobaltieri previously approved these changes Nov 11, 2025

View reviewed changes

keith-zephyr reviewed Nov 12, 2025

View reviewed changes

GTLin08 dismissed fabiobaltieri’s stale review via d33aafc November 13, 2025 03:07

GTLin08 force-pushed the it8xxx2_kernel_in_ram_lto branch from 123ab0b to d33aafc Compare November 13, 2025 03:07

RuibinChang mentioned this pull request Nov 13, 2025

soc/ite/it8xxx2/kconfig: add warning for enable ram code with LTO #97432

Closed

GTLin08 force-pushed the it8xxx2_kernel_in_ram_lto branch from d33aafc to 7171255 Compare November 13, 2025 06:40

fabiobaltieri previously approved these changes Nov 13, 2025

View reviewed changes

keith-zephyr reviewed Nov 13, 2025

View reviewed changes

keith-zephyr previously approved these changes Nov 14, 2025

View reviewed changes

JarmouniA reviewed Nov 16, 2025

View reviewed changes

kernel/Kconfig Show resolved Hide resolved

kernel/kernel_no_lto.cmake Show resolved Hide resolved

kernel/kernel_no_lto.cmake Outdated Show resolved Hide resolved

JarmouniA requested a review from nordicjm November 16, 2025 10:10

GTLin08 dismissed stale reviews from keith-zephyr and fabiobaltieri via ed42e77 November 17, 2025 03:03

GTLin08 force-pushed the it8xxx2_kernel_in_ram_lto branch from 7171255 to ed42e77 Compare November 17, 2025 03:03

fabiobaltieri previously approved these changes Nov 17, 2025

View reviewed changes

keith-zephyr previously approved these changes Nov 17, 2025

View reviewed changes

nordicjm reviewed Nov 19, 2025

View reviewed changes

GTLin08 added 2 commits November 21, 2025 18:27

soc: it8xxx2: Select KERNEL_NO_LTO only when LTO is enabled

5e9e169

Select KERNEL_NO_LTO only when LTO is enabled. This ensures proper handling when kernel code is placed in RAM. Signed-off-by: Tim Lin <tim2.lin@ite.corp-partner.google.com>

GTLin08 dismissed stale reviews from keith-zephyr and fabiobaltieri via 5e9e169 November 21, 2025 11:00

GTLin08 force-pushed the it8xxx2_kernel_in_ram_lto branch from ed42e77 to 5e9e169 Compare November 21, 2025 11:00

		# Append the injected code to the end of the file
		file(APPEND ${KERNEL_CMAKE} "${INJECT_CODE}")

kernel: Add Kconfig option to disable LTO for kernel sources #99124

Are you sure you want to change the base?

kernel: Add Kconfig option to disable LTO for kernel sources #99124

Conversation

GTLin08 commented Nov 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GTLin08 commented Nov 13, 2025

Uh oh!

fabiobaltieri left a comment

Choose a reason for hiding this comment

Uh oh!

npitre commented Nov 13, 2025 via email

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GTLin08 commented Nov 14, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

GTLin08 commented Nov 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud bot commented Nov 21, 2025

Quality Gate passed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

11 participants

GTLin08 commented Nov 8, 2025 •

edited

Loading